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The technical field of this invention is complex 
integrated circuits including embedded digital processor cores 
and more particularly in circuit emulation of integrated 
5 circuits with embedded digital processor cores. 



RArKnPOTJND OF THK TNVFNTTON 



Programmable digital processors such as microprocessors 
and digital signal processors have become very complex 
machines. Testing these programmable digital processors has 

10 also become complex task. It is now common for semiconductor 
manufactures to build single integrated circuit programmable 
digital processors with millions of transistors. The current 
trend is to devote many of these transistors to on-chip cache 
memories. Even so, the number of logic circuits and their 

15 complex relationships makes testing such integrated circuits 
an increasingly difficult task. 

A trend in electronics makes this testing problem more 
difficult. Single integrated circuit programmable digital 
processors are becoming more and more of the electronics of 

20 many end products. A single integrated circuit used in this 
way typically includes a programmable digital processor, read 
only memory storing the base program, read/write memory for 
operation and a set of peripherals selected for the particular 
product. This trend is known as system level integration. In 

25 the ultimate system level integration, all the electronics are 
embodied in a single integrated circuit. This level of 
integration is now achieved in electronic calculators. Many 
electronic calculators consist of a single integrated circuit. 
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a keyboard, a display, the battery or solar panel power source 
and a plastic case. Such integration provides less 
"visibility" into the operation of the programmable digital 
signal processor. Because the address and data busses of the 
5 digital processor are no longer brought out the device pins, 
it is more difficult to determine the behavior of the embedded 
processor from external connections. 

Another trend in electronics makes this testing problem 
more difficult. Many new product applications require 

10 differing types of processing. Often control processes and 
user interface processes are better handled with a different 
programmable digital processor than digital signal processes. 
An example is wireless telephones . Many coding/decoding and 
filtering tasks are best handled by a digital signal processor 

15 (DSP) . Other tasks such as dialing, controlling user inputs 
and outputs are best handled by microprocessors such as a RISC 
(Reduced Instruction Set Computer) processor. There is a 
trend for a system integrated circuit to include both a RISC 
processor and a DSP. These two processors will typically 

20 operate independently and employ differing instruction set 
architectures . Thus there may be more than one programmable 
digital processor on a single integrated circuit, each having 
limited visibility via the device pins. 

Another problem is product emulation when employing these 

25 programmable digital processors. Product development and 
debugging is best handled with an emulation circuit closely 
corresponding to the actual integrated circuit to be employed 
in the final product. In circuit emulation (ICE) is in 
response to this need. An integrated circuit with ICE 

3 0 includes auxiliary circuit not needed in the operating product 
included solely to enhance emulation visibility. In the 
typical system level integration circuit, these emulation 
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circuits use only a very small fraction of the number of 
transistors employed in operating circuits. Thus it is 
feasible to include ICE circuits in all integrated circuits 
manufactured. Since every integrated circuit can be used for 
5 emulation, inventory and manufacturing need not differ between 
a normal product and an emulation enhanced product. 

As a result of these trends there is a need in the art 
for integrated circuits which are easier to test and easier to 
emulate . 
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This invention involves in-circuit-emulation of an 
integrated circuit . The integrated circuit includes a digital 
data processor capable of executing program instructions. A 
5 debug event detector detects predetermined debug event. Upon 
detection of a debug event, the in-circuit-emulator suspends 
program execution except for real time interrupts. An 
emulation monitor program permitting visibility into the state 
of the integrated circuit is run as such a real time interrupt 

10 interrupt. 

The integrated circuit includes a serial scan path for 
control of the state of the integrated circuit, such as a JTAG 
interface. The in-circuit-emulation selectively assigning 
emulation resources of the integrated circuit to one of the 

15 serial scan path or the monitor program. A monitor privilege 
input controls this assignment by its digital state. The -fe^r 
emulation resource may be a read write data register and he 
assignment includes accessing the data register. 
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These and other aspects of this invention are illustrated 
in the drawings, in which: 

Figure 1 illustrates the environment of the debugging 
5 system of this invention which is known in the art; 

Figure 2 illustrates the known 14 -pin JTAG header used to 
interface the target system to the access adapter; 

Figure 3 illustrates an emulation level view of the 
target system; 

10 Figure 4 illustrates an electrical connection view of the 

coupling between the access adapter and the target system; and 
Figure 5 illustrates the possible operation states in the 
debugging environment of the preferred embodiment of this 
invention. 
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Figure 1 illustrates the environment of the debugging 
system of this invention. This environment connects high 
level debugging software executing on a debug host computer 1 
to a low level debug interface supported by the target system 
3 . In this invention the target system 3 may include more 
than one programmable digital processor and possibly more than 
one such programmable digital processor on a single integrated 
circuit. In this application the term programmable digital 
processor is meant to encompass devices commonly known as 
microprocessors, • microcontrollers and digital signal 
processors. The target system 3 provides a standard interface 
to the access adapter 2 . 

Debug host computer 1 consists of a computer, for example 
a 'PC7~"rnimingL_a^CPU core specific software debugger as one of 
its tasks. The debug^Tio^r-xr©mput.^r^ the user to issue 

high level commands such as setting -b^ie^Jcpoint , single 
stepping the programmable digital processor in taxget--S5igtem 
3 and displaying the contents of a memory range. 

' Access adapter 2 is a combination of hardware and 
software that connects the debug host computer 1 to target 
system 3. Access adapter 2 utilizes one or more hardware 
interfaces and/or protocols to convert messages created by 
user interface commands of debug host computer 1 into debug 
commands operable on target system 3 . Access adapter 2 can be 
either loosely coupled or tightly coupled to the debug host 
computer 1. In the case of a PC host computer, access adapter 
3 can be an XDS 510 scan controller attached directly to the 
PC bus. This implements a tightly coupled configuration 
requiring the PC to perform even the lowest level actions 
necessary to manage debug activity. In loosely coupled 
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configurations, debug host computer 1 CPU communicates with 
another processor over a high bandwidth interface such as a 
SCSI, LAN or other interface. An example of this is a XDS 
510WS controller connected to the target system debug 
5 interface and to the PC through a SCSI port. In this case 
access adapter 2 is a debug subsystem manager and handles the 
detailed manipulation of the target debug capability, and 
debug host computer 1 send high level commands to the debug 
subsystem. Access adapter 2 returns data and error conditions 
10 to debug host computer 1. Current PC operating systems may 
not be able to service the low level debug requirements 
continuously. Thus it may be advantageous to partition the 
problem into the display and user interface and control 
sections. 

15 The target system 3 contains one or more programmable 

digital processor cores. The programmable digital processor 
core(s) contain hardware designed explicitly to ease 
debugging. This special hardware of target system 3 is the 
lowest element of the system debug environment 10. The 

20 programmable digital processor core debug facilities allow the 
user to control the program execution, examine or change 
system memory, core CPU resources in real-time. 

The interface of access adapter 2 to target system 3 is 
preferably an extension to the IEEE 1149.1 (JTAG) test 

25 standard. The JTAG standard includes 5 primary signals known 
as nTRST, TCK, TMS, TDI, and TDO. The JTAG standard typically 
employs three additional signals Test Clock Out (TCKO) , the 
target supply (Vdd) and ground (GND) . The preferred embodiment 
of this invention also employs the two extension signals nETl 

30 and nETO . Table 1 lists these signals, states whether the 
signal is an input, an output or both, and gives the 
descriptive name of the signal. 
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Pin 


Type 
Input /Output 


Description 


nTRST 


I 


Test Logic Reset Not 


TCK 


I 


Test Clock 


TMS 


I 


Test Mode Select 


TDI 


I 


Test Data Input 


TDO 


0 


Test Data Output 


TCKO 


0 


Test Clock Out 


PD (Vdd) 


I 


Target Power Supply- 


GND 


I/O 


Ground 


nETl 


I/O 


Emulation and Test 1 Not 


nETO 


I/O 


Emulation and Test 0 Not 



Table 1 



The signal nTRST is called Test Logic Reset Not. A low 
applied to this pin causes all test and debug logic in the 
15 target device to be reset along with the IEEE 1149.1 
interface . 

The signal TCK is called Test Clock. This signal is used 
to drive the IEEE 1149.1 state machine and logic. The same 
TCK supplied to the target device is supplied to this pin. 
20 The signal TMS is called Test Mode Select. This signal 

directs the next state of the IEEE 1149.1 test access port 
state machine. 

The signal TDI is called Test Data Input. This signal is 
the scan data input to the target device . 
25 The signal TDO is called Test Data Output. This signal 

is the scan data output of the target device. 

Figure 2 illustrates a 14 -pin JTAG header used to 
interface target system 3 to access adapter 2 . The JTAG 
. header requires three additional pins, and further includes 
30 two extension pins. The signal TCKO is called Test Clock Out. 
This signal is a test clock supplied by the scan controller to 
the target system. This test clock can be used as the system 
TCK source, or it can be ignored with the TCK source being 
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generated by the target system. In many target systems, TCKO 
is simply connected to TCK and used as the test clock. The 
PD(Vdd) is called the Target Power Supply. This is used as a 
power detect input to access adapter 2 . The JTAG header also 
5 includes ground connections. 

The preferred embodiment of this invention includes an 
^extension to the JTAG interface. Two pins nETO and nETl serve 
as a^l^wQ^pin trigger channel function. This function 
supplements tKS^-^^erial access capability of the standard 
10 interface with contirulous monitoring of device activity. The 
two added pins create debug^iK^test capabilities that cannot 
be created with the standard intet€^e . The nETO signal is 
called Emulat ion and Test 0 Not . This ^Sigrial helps create a 
trigger to channel zero. Similarly, the nETlsl^nal is called 
15 Emulation and Test 0 Not. This signal helps create^a>^igger 
to channel one. These channels will be further explained 
below. 

Figure 3 illustrates an emulation level view of target 
system 3. Target system 3 may include plural devices 11, 13 

20 and 15. Figure 3 illustrates details of example device 13 
which includes plural megamodules 21, 23 and 25. Figure 3 
illustrates details of example megamodules 23. Example 
megamodule 23 includes debug and test control unit 30 and 
plural device domains. These device domains include central 

25 processing unit (CPU) core 31, analysis unit 33, memory 35 and 
debug/test direct memory access (DT_DiyiA) unit 37. 

Debug and test control unit 3 0 contains the IEEE 
interface. It provides a bridge between the Extended IEEE 
Interface and the debug and test capability distributed 

30 through the domains. Debug and test control unit 30 can 
independently control by the domains 31, 33, 3 5 and 37. In 
other words, one or more domains can be scanned or controlled 
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their normal 



while other domains 
functional way. 

Figure 4 illustrates an electrical connection view of the 
cSugL^J^g between access adapter 2 and target system 3 . Figure 
4 shows^th^connections of the of the various signals of the 
JTAG header 5i>a^strated in Figure 2 . All these signals are 
connected to scan controller 41. The signals nTRST, TCK and 
TMS are connected to^^t^ example megamodules 31 and 33. 
Figure 4 illustrates the o^fe4^nal connection of TCKO to the 
target system clock SYSCLK. The^^^s^n input TDI connects to a 
scan input of megamodule 31. The scari^^tput of megamodule 31 
supplies the scan input of eg module 33 .^^The scan output of 
meg module 33 supplies the scan output TDO. Tnfev^wo extension 
signals nETO and nETl control meg modules 31 and 3><^a merge 
unit 32. These extension signals are monitored by\^est 
equipment 43. 

The debugging environment illustrated in Figures Itp- 4 
permit the user to control application execu^ierT'^by any 
programmable digital processor of targe^^^^aystem 3 . Typical 
control processes include: keyboajid-^^orectives such as run, 
halt and step; software brgaJc^Soint using op- code replacement; 
internal analysi^s^H^feakpoint specified program counter or 
watchpoint'^'^specif ied by data accesses; and externally 
ferated debug events. 

Actions such as decoding a software breakpoint 
■.ion (DSTOP) , the occurrence of an analysis breakpoint 

or the occurrence of a debug host 
is debug events . Debug 
Debug eveivfs-^tied to the 



insCl 

or watchpoint 

computer event (HSTOP) are reEei 
events cause execution to suspend. 

execution of specific instructions are called breakpolTrlt 
Debug events generated by memory references are called 
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>^ watchpoints^ Extern al dobug oA^n t R ran al s o suspend execi itjren-r- 
.Bebug events cause entry into the Debug State. 

Figure 5 illustrates the possible operation states in the 
debugging environment of the preferred embodiment of this 
5 invention. These operation states are execute (EXE) 101, 
debug suspend (DSUSP) 102 and interrupt during debug suspend 
(IDS) 103. 

Execute state 101 corresponds to the ordinary operation 
of target device 3. In the execute state 101 instructions are 

10 executed by the programmable digital processor in normal 
fashion. There are no outstanding debug suspend conditions. 
A low logic level applied to the nTRST terminal or a software 
directive requesting functional run forces the operational 
state to execute state 101. In execute state 101 the pipeline 

15 fetches and executes instructions and process interrupts in a 
normal way. 

The operational state transits from execute state 101 to 
debug SA^pend state 102 upon a debug event. The debugging 
environment^ of the preferred embodiment of this invention 
20 allows the suspension of program execution at points defined 
by breakpoint, w^^hpoints, and debug software directives, 
provided the application is an allowable debug suspend window. 
In general, debug eveh4;^ are allowed at an instruction 
boundary, when reset is inab<;J.ve and no interrupts are active. 
25 Program execution suspends at an instruction boundary and the 
operational state changes to debug suspend state 102 . When 
any debug condition is not met, the ^>^erational state remains 
in execute state 101 and no debug eve^ processing occurs. 
The debugging environment permits debug eV^t processing in 
30 the delayed slots of delaiyed branch instrubt;ions . Debug 
events occurring outside the debug suspend windbw create a 
debug pending condition. This condition suspends^i^ogram 
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execution when the appl ication enables, 
Lng the aebug suspend window. 
In the debug suspend state 102 background instruction 
execution is inactive. This state permits debug/emulation 
visibility into the state of target device 3 while background 
execution is suspended. In debug suspend state 102, the 
program counter (PC) and status bits are generally preserved 
at their values prior to the debug event. The PC points to 
the instruction to be executed next. When execution resumes, 
the instruction referenced by the PC and those following is 
fetched for execution. This is facilitated by flushing the 
front end of the pipeline upon entry into debug suspend state 
102 from execute state 101. 

The operational state may return to execute state 101 by 
a debug run directive. This may be either an unconditional 
run directive or a single step run directive. A single step 
run directive enters execute state 101 long enough to advance 
the instruction pipeline one stage and then returns to debug 
suspend state 102. 

It is important to note that debug suspend state 102 
consumes no CPU bandwidth because no monitor code executes as 
a result of suspending execution. The debug architecture 
provides for complete register and memory accessibility 
without the aid of a monitor program. The user may change the 
operating mode at any time without restrictions. 

Certain interrupts transit the operation state from debug 
strspejad^^tate 102 to interrupt during suspend (IDS) state 103. 
These interr^pts^a^^e-^defd^d by a separate interrupt mask 
independent of the normal inter^up1>-ma.slc. Those interrupts 
defined as high priority interrupts (HPlT 0"^-.....Joreground 
interrupts cause the operation state to enter the interrupt 
during suspend state 103 from the debug suspend state 102 . 
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The debug suspend state 102 enables high priority interrupts 
"^- XnHpppn<iprtt of the state of t he global interrupt enable bit or 
, of software run directives. tKis — eaables debugging of 
background tasks while the target device 3^cbnt4nues to 
5 service a real time application via high priority interrttpts . 

The interrupt pipeline jam for such a high priority 
interrupt moves the operational state to interrupt during 
suspend state 103. This jam causes an extra word to be pushed 
on the stack containing the debug status describing the reason 
10 the debug suspend state 102 entry occurred. Interrupt during 
suspend state 103 differs from the execute state 101 in that 
the interrupt processing creates a thread, linking the 
interrupt execution to the debug suspend state 102 as 
described in above. A digital frame counter (DFC) is 
15 incremented upon each high priority interrupt taken. The 
high priority interrupt sets an interrupt during debug state 
bit (IDS), which is part of the CPU status. The IDS bit sets 
after the context save stores the previous value on the stack 
with the status word. When returning from an interrupt the 
20 IDS bit indicates whether to re-enter debug suspend state 102. 
If the IDS bit is set, the interrupt occurred during a debug 
suspend state 102 and the operational state should return to 
the debug suspend state 102. If the IDS bit is not set, the 
interrupt occurred during the execute state 101 and the 
25 operational state should return to execute state 101. Upon 
returning from the interrupt, the PC and status return to 
their state before the interrupt unless the interrupt service 
routine has purposely modified values on the stack. This is 
required because it is possible for multiple interrupts to 
30 occur and be serviced while the device is in debug suspend 
state 102. 
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The digital frame counter is decremented upon each return 
from interrupt. This count permits the debug environment to 



assured no interrupts have not temporarily changed the machi^^e 
state . 



end of the interrupt service routine. A normal end of an 
interrupt involves a return from interrupt instruction (RTI) . 
Upon execution of a return from interrupt instruction, the 
machine status is popped from the stack. As noted above, the 

15 interrupt during debug state bit indicates whether the 
interrupt occurred during execute state 101 or debug suspend 
state 102. The operational state return to the former state 
as indicated by the interrupt during debug state bit . The 
prior value of the program counter is reloaded to recover the 

20 prior machine status. Execution of a return from interrupt 
instruction also decrements the digital frame counter. 
Because it is possible to receive a higher priority interrupt 
while servicing a prior interrupt, more than one interrupt 
level may be pending. The digital frame counter indicates the 

25 current interrupt level. This is useful to debug processing 
as the machine status may be changed by the multiple 
interrupts. The debug software can read the digital frame 
counter and supply a debug level identity to identify 
currently targeted interrupt level. Execution and register 

30 operations target a specific debug level. Memory operations 
can target a specific debug level or bypass the level 
comparison. In particular, the status of the background task 




10 



The interrupt during suspend state 103 is exited at the 
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suspended on initial entry into debug suspend state 102 can 
only be reliably determined if the digital frame counter is 
zero. The maximum number of levels of the digital frame 
counter corresponds to the size of the interrupt hierarchy. 
5 This data preserves a path back to the debug suspend state 102 
when the application concludes the interrupt service routine 
with a return from interrupt instruction. 

The interrupt during suspend state 103 transits to the 
execute state 102 upon execution of an abort interrupt 
10 (ABORTI) instruction. The abort interrupt instruction would 
ordinarily be used only on detection of a unrecoverable error 
in the interrupt service routine. The path back to the debug 
^ suspend state is broken upon execution of the abort interrupt 

? instruction. The status of the interrupt during debug state 

ffl 15 bit and the digital frame counter are ignored in this case, 
p In particular, the interrupt during debug state bit is cleared 

SJ. and the digital frame counter is set to zero. This mechanism 

^ enables recovery to the background task when a high priority 

p interrupt service routine has an unrecoverable error. 

20 Interrupts can be serviced the while the debug software 

V views or modifies the CPU state. The debug state shown to the 

O programmer reflects the machine state when there is no 

^ interrupt service routine active. The debug software works 

with on-chip debug support to ensure the high priority 
25 interrupts are transparent to a debug session. Likewise this 
hardware and software combination works to make debug activity 
transparent to high priority interrupt service routines. Note 
that program execution can actually be suspended in multiple 
locations if it is desired to break within a time critical 
30 interrupt while still allowing others to be serviced. 

Table 2 lists all the debug related registers included in 
each megamodule. Miscellaneous control bits supporting the 
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JTAG interface are not included in this list. Most but not 
all of the debug unit registers are placed in the memory map 
so they are accessible by both debug software and the 
application. There are three levels of register access: 
5 registers always shared by the application and debug 
facilities; registers accessed through the extended JTAG port 
* only; and registers accessed through the extended JTAG port or 
a specially privileged monitor program but not shared. 

The application and debug software share registers 

10 controlling external trigger event inputs, breakpoints and 
watchpoints, data logging, parallel signature analysis, and 
count functions. The application and debug software can not 
simultaneously own these resources but establish ownership and 
release ownership through memory mapped control registers 

15 continuously visible to both the application and debug 
software. The debug software has the ability to seize any 
resource if necessary, or negotiate with the application 
through software sequences. 

Other registers are specific to JTAG scan support and can 

20 never be accessed by the application. This class of registers 
is clocked with TCK and includes the JXREG, GPSR. EXSR, and 
IR_LTCH registers. Another register, the MF_REGS_1 register 
is clocked with FCK but is not accessible to the application. 
This register controls the device operational state as 

25 illustrated in Figure 5, special reset modes, test modes, 
clock source selection and the like. 

A third class of registers is accessible through JTAG and 
accessible to the application if a special privileges are 
granted to a monitor function via a megamodule terminal 

30 MON_PRIV. When this terminal is grounded the application 
cannot access this register class. When this terminal is a 
logic 1, the application code can access a debug control 
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register normally controlled by JTAG scans. This register 
contains nETO and nETl pin control, execution control and the 
debug frame reference register. 

During normal operation, when iy[ON_PRIV is a 1, the 
5 application owns the MF_REGS_0 resources. They cannot be 
accessed via JTAG scan as this amounts to dual allocation of 
resources. The monitor program must manage execution control 
and other debug resources. The monitor program can 
communicate with the debug software through a serial port or 

10 other mechanism that is not the JTAG interface. This allows 
the extended JTAG port to be operated in the Hidden IEEE 
1149.1 format. This allows the application to assign system 
functions to all or some or all of the extended JTAG port 
pins, with the extended JTAG port available for production 

15 test. The drawbacks of this approach are simply diminished 
capability on a number of fronts. 

This approach requires a monitor program and additional 
memory resources. The data logging capabilities through the 
JTAG interface are lost. This approach brings along with it 

2 0 the traditional class of problems associated with asynchronous 
communication that may be laced with resets and other system 
upsets. In spite of these disadvantages, the advantages of 
using a system communication mechanism with a smaller number 
of debug related pins can out weigh the disadvantages in some 

25 systems. 
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Width 


Memory Mapped 


•Register 
Nstne 


Description 






8 


No 


IR_LTCH 


Latched Instruction 
Ksgxsceir 






6 


No 


EXSR 


Extended Shift 
Register 






32 


No 


JXREG 


JTAG Transfer 
Register 




D 


J Z 


i>JO 




General Purpose Shift 
Reg . 








JMO^ ^ 




Functional Transfer 
Kegi s cer 












Misc. Function 
Register 1 






^ z 


I 6S 


MI? 'DTPr'c n 


Misc. Function 

A T o ^ A v~ ^ 

Kcyisuer u 






-L \j 




DRn QTZiTTTQ 

iJlj\D O X r\ JL U O 


i-zcXjUy o UaUUS 


. 


1 n 
± U 


xd 


Vila c 


Il*V-iN i Xl 


External Event 












^oriu rox 






16 


Yes 


ACNTL 


Address Unit Control 








X c o 




r\LlX fa . luafaK. l\.eyXSL.ci 






32 


Yes 


AREF 


Adrs . Reference 












Register 






16 


Yes 


DCNTL 


Data Unit Control 




15 


32 


Yes 


OMSK 


Data Mask Register 






32 


Yes 


DREF 


Data Reference 












Register 






16 


Yes 


HPIR 


High Priority . 
Interrupt Reg. 



** Monitor privileged writes to MF_REG_0 use the FXREG as a 
temporary register. 



20 Table 2 

Table 3 shows the memory map register order for the 
sixteen debug registers placed in the memory map. Debug 
registers are accessed as 32 bit values for debug while the 
application may access them as 32 bit register pairs or 
25 sixteen bit registers when the underlying CPU architecture 
supports only 16 bit data. Registers fourteen and fifteen are 
accessible in the memory map when the MON_PRIV megamodule 
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terminal is TRUE. These two registers are write only. A bit 
in an scan accessible register also enables this mode. 







Reg.# 


Register Name 


Read 


Write 


Description 






19 


CMSGH 


No 


Yes 


Cmd . Msg . Reg . 
High 




5 


18 


CMSGL 


No 


Yes 


Cmd. Msg Reg. Low 






17 


DMSGH 


No 


Yes 


Data Msg. Reg. 
High 






16 


DMSGL 


No 


Yes 


Data Msg Reg. Low 






15 


MF_REGS_0H 


No 


Mon . 


Misc . Func . Reg. 0 
High 






14 


MF_REGS_0L 


No 


Mon . 


Misc . Func . Reg. 0 
Low 




10 


13 


Reserved 







Reserved 






12 


DBG STAT 


Yes 


Yes 


Debug Status 






11 


ECNTL 


Yes 


Yes 


External Unit 
Control 






10 


DCNTL 


Yes 


Yes 


Data Unit Control 


w 




09 


DREFH 


Yes 


Yes 


Data Ref. Reg. 
High 




15 


08 


DREFL 


Yes 


Yes 


Data Ref. Reg. Low 






07 


DMSKH 


Yes 


Yes 


Data Mask Reg. 
High 






06 


DMSKL 


Yes 


Yes 


Data Mask Reg. Low 






05 


AREFH 


Yes 


Yes 


Adrs. Ref. Reg. 
High 






04 


AREFL 


Yes 


Yes 


Adrs. Ref. Reg. 
Low 




20 


03 


AMSKH 


Yes 


Yes 


Adrs. Mask Reg. 
High 






02 


AMSKL 


Yes 


Yes 


Adrs. Mask Reg. 
Low 






' 01 


ACNTL 


Yes 


Yes 


Address Unit 
Control 






00 


HPIR 


Yes 


Yes 


High Priority Int . 
Reg. 



Table 3 



25 The EXSR, GPSR and JXREG registers are clocked with the 

test clock (TCK) and are only accessible via the extended JTAG 
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port. The EXSR and GPSR provide the instruction and data 
register scan paths . The JXREG provides an a holding register 
for the GPSR contents. Data is copied from the GPSR to the 
JXREG any time the GPSR data needs to be transferred to 
5 another register. Since these registers are basic components 
of the scan path and are not tightly coupled to functional 
logic, they are inaccessible to the application. Update JTAG 
states and fast downloads actions cause these transfers. When 
operating in imbedded command mode, the GPSR is also moved to 
10 the JXREG for disposition. 
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